home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / The World of Computer Software.iso / macutils.zip / readme.1 < prev    next >
Text File  |  1992-11-19  |  23KB  |  484 lines
  1. This is version 2.0b3 of macutil (22-OCT-1992).
  2.  
  3. This package contains the following utilities:
  4.     macunpack
  5.     hexbin
  6.     macsave
  7.     macstream
  8.     binhex
  9.     tomac
  10.     frommac
  11.  
  12. Requirements:
  13. a.  Of course a C compiler.
  14. b.  A 32-bit machine with large memory (or at least the ability to 'malloc'
  15.     large chunks of memory).  For reasons of efficiency and simplicity the
  16.     programs work 'in-core', also many files are first read in core.
  17.     If somebody can take the trouble to do it differently, go ahead!
  18.     There are also probably in a number of places implicit assumptions that
  19.     an int is 32 bits.  If you encounter such occurrences feel free to
  20.     notify me.
  21. c.  A Unix (tm) machine, or something very close.  There are probably quite
  22.     a lot of Unix dependencies.  Also here, if you have replacements, feel
  23.     free to send comments.
  24. d.  This version normally uses the 'mkdir' system call available on BSD Unix
  25.     and some versions of SysV Unix.  You can change that, see the makefile for
  26.     details.
  27.  
  28. File name translation:
  29.  
  30. The programs use a table driven program to do Mac filename -> Unix filename
  31. translation.  When compiled without further changes the translation is as
  32. follows:
  33.     Printable ASCII characters except space and slash are not changed.
  34.     Slash and space are changed to underscore, as are all characters that
  35.     do not fall in the following group.
  36.     Accented letters are translated to their unaccented counterparts.
  37. If your system supports the Latin-1 character set, you can change this
  38. translation scheme by specifying '-DLATIN1' for the 'CF' macro in the
  39. makefile.  This will translate all accented letters (and some symbols)
  40. to their Latin-1 counterpart.  This feature is untested (I do not have
  41. access to systems that cater for Latin-1), so use with care.
  42. Future revisions of the program will have user settable conversions.
  43.  
  44. Another feature of filename translation is that when the -DNODOT flag is
  45. specified in the CF macro an initial period will be translated to underscore.
  46.  
  47. MacBinary stream:
  48.  
  49. Most programs allow MacBinary streams as either input or output.  A
  50. MacBinary stream is a series of files in MacBinary format pasted
  51. together.  Embedded within a MacBinary stream can be information about
  52. folders.  So a MacBinary stream can contain all information about a
  53. folder and its constituents.
  54.  
  55. Appleshare support:
  56.  
  57. Optionally the package can be compiled for systems that support the sharing
  58. of Unix and Mac filesystems.  The package supports AUFS (AppleTalk Unix File
  59. Server) from CAP (Columbia AppleTalk Package) and AppleDouble (from Apple).
  60. It will not support both at the same time.  Moreover this support requires
  61. the existence of the 'mkdir' system call.  And finally, as implemented it
  62. probably will work on big-endian BSD compatible systems.  If you have a SysV
  63. system with restricted filename lengths you can get problems.  I do not know
  64. also whether the structures are stored native or Apple-wise on little-endian
  65. systems.  And also, I did not test it fully; having no access to either AUFS
  66. or AppleDouble systems.
  67.  
  68. Acknowledgements:
  69. a.  Macunpack is for a large part based on the utilities 'unpit' and 'unsit'
  70.     written by:
  71.     Allan G. Weber
  72.     weber%brand.usc.edu@oberon.usc.edu
  73.     (wondering whether that is still valid!).  I combined the two into a
  74.     single program and did a lot of modification.  For information on the
  75.     originals, see the files README.unpit and README.unsit.
  76. b.  The crc-calculating routines are based on a routine originally written by:
  77.     Mark G. Mendel
  78.     UUCP: ihnp4!umn-cs!hyper!mark
  79.     (this will not work anymore for sure!).  Also here I modified the stuff
  80.     and expanded it, see the files README.crc and README.crc.orig.
  81. c.  LZW-decompression is taken from the sources of compress that are floating
  82.     around.  Probably I did not use the most efficient version, but this
  83.     program was written to get it done.  The version I based it on (4.0) is
  84.     authored by:
  85.     Steve Davies            (decvax!vax135!petsd!peora!srd)
  86.     Jim McKie               (decvax!mcvax!jim)  (Hi Jim!)
  87.     Joe Orost               (decvax!vax135!petsd!joe)
  88.     Spencer W. Thomas       (decvax!harpo!utah-cs!utah-gr!thomas)
  89.     Ken Turkowski           (decvax!decwrl!turtlevax!ken)
  90.     James A. Woods          (decvax!ihnp4!ames!jaw)
  91.     I am sure those e-mail addresses also will not work!
  92. d.  Optional AUFS support comes from information supplied by:
  93.     Casper H.S. Dik
  94.     University of Amsterdam
  95.     Kruislaan  409
  96.     1098 SJ  Amsterdam
  97.     Netherlands
  98.  
  99.     phone: +31205922022
  100.     email: casper@fwi.uva.nl
  101.     This is an e-mail address that will workm but the address and phone
  102.     number ar no longer valid.
  103.     See the makefile.
  104.     Some caveats are applicable:
  105.     1.  I did not fully test it (we do not use it).  But the unpacking
  106.     appears to be correct.  Anyhow, as the people who initially compile
  107.     it and use it will be system administrators I am confident they are
  108.     able to locate bugs!  (What if an archive contains a Macfile with
  109.     the name .finderinfo or .resource?  I have had two inputs for AUFS
  110.     support [I took Caspers; his came first], but both do not deal with
  111.     that.  Does CAP deal with it?)  Also I have no idea whether this
  112.     version supports it under SysV, so beware.
  113.     2.    From one of the README's supplied by Casper:
  114.         Files will not appear in an active folder, because Aufs doesn't like
  115.         people working behind it's back.
  116.         Simply opening and closing the folder will suffice.
  117.     Appears to be the same problem as when you are unpacking or in some
  118.     other way creating files in a folder open to multifinder.  I have seen
  119.     bundle bits disappear this way.  So if after unpacking you see the
  120.     generic icon; check whether a different icon should appear and check
  121.     the bundle bit.
  122.         The desktop isn't updated, but that doesn't seem to matter. 
  123.     I dunno, not using it.
  124. e.  Man pages are now supplied.  The base was provided by:
  125.     Douglas Siebert
  126.     ISCA
  127.     dsiebert@icaen.uiowa.edu
  128. f.  Because of some problems the Uncompactor has been rewritten, it is now
  129.     based on sources from the dearchiver unzip (of PC fame).  Apparently the
  130.     base code is by:
  131.     Samuel H. Smith
  132.     I have no further address available, but as soon as I find a better
  133.     attribution, I will include it.
  134. g.  UnstuffIt's LZAH code comes from lharc (also of PC fame) by:
  135.     Haruhiko Okumura,
  136.     Haruyasu Yoshizaki,
  137.     Yooichi Tagawa.
  138. h.  Zoom's code comes from information supplied by Jon W{tte
  139.     (d88-jwa@nada.kth.se).  The Zoo decompressor is based on the routine
  140.     written by Rahul Dhesi (dhesi@cirrus.COM).  This again is based on
  141.     code by Haruhiko Okumura.  See also the file README.zoom.
  142. i.  MacLHa's decompressors are identical to the ones mentioned in g and h.
  143. j.  Most of hexbin's code is based on code written/modified by:
  144.     Dave Johnson, Brown University Computer Science
  145.     Darin Adler, TMQ Software
  146.     Jim Budler, amdcad!jimb
  147.     Dan LaLiberte, liberte@uiucdcs
  148.     ahm (?)
  149.     Jeff Meyer, John Fluke Company
  150.     Guido van Rossum, guido@cwi.nl (Hi!)
  151.     (most of the e-mail addresses will not work, the affiliation may also
  152.     be incorrect by now.)  See also the file README.hexbin.
  153. k.  The dl code in hexbin comes is based on the original distribution of
  154.     SUMacC.
  155. l.  The mu code in hexbin is a slight modification of the hcx code (the
  156.     compressions are identical).
  157. m.  The MW code for StuffIt is loosely based on code by Daniel H. Bernstein
  158.     (brnstnd@acf10.nyu.edu).
  159. n.  Tomac and frommac are loosely based on the original macput and macget
  160.     by (the e-mail address will not work anymore):
  161.     Dave Johnson
  162.     ddj%brown@csnet-relay.arpa
  163.     Brown University Computer Science
  164.  
  165. -------------------------------------------------------------------------------
  166. Macunpack will unpack PackIt, StuffIt, Diamond, Compactor/Compact Pro, most
  167. StuffItClassic/StuffItDeluxe, and all Zoom and LHarc/MacLHa archives, and
  168. archives created by later versions of DiskDoubler.
  169. Also it will decode files created by BinHex5.0, MacBinary, UMCP,
  170. Compress It, ShrinkToFit, MacCompress, DiskDoubler and AutoDoubler.
  171.  
  172. (PackIt, StuffIt, Diamond, Compactor, Compact/Pro, Zoom and LHarc/MacLHa are
  173. archivers written by respectively: Harry R. Chesley, Raymond Lau, Denis Sersa,
  174. Bill Goodman, Jon W{tte* and Kazuaki Ishizaki.  BinHex 5.0, MacBinary and
  175. UMCP are by respectively: Yves Lempereur, Gregory J. Smith, Information
  176. Electronics.  ShrinkToFit is by Roy T. Hashimoto, Compress It by Jerry
  177. Whitnell, and MacCompress, DiskDoubler and AutoDoubler are all by
  178. Lloyd Chambers.)
  179.  
  180. * from his signature:
  181.     Jon W{tte - Yes, that's a brace - Damn Swede.
  182. Actually it is an a with two dots above; some (German inclined) people
  183. refer to it (incorrectly) as a-umlaut.
  184.  
  185. It does not deal with:
  186. a.  Password protected archives.
  187. b.  Multi-segment archives.
  188. c.  Plugin methods for Zoom.
  189. d.  MacLHa archives not packed in MacBinary mode (the program deals very
  190.     poorly with that!).
  191.  
  192. Background:
  193. There are millions of ways to pack files, and unfortunately, all have been
  194. implemented one way or the other.  Below I will give some background
  195. information about the packing schemes used by the different programs
  196. mentioned above.  But first some background about compression (I am no
  197. expert, more comprehensive information can be found in for instance:
  198. Tomothy Bell, Ian H. Witten and John G. Cleary, Modelling for Text
  199. Compression, ACM Computing Surveys, Vol 21, No 4, Dec 1989, pp 557-591).
  200.  
  201. Huffman encoding (also called Shannon-Fano coding or some other variation
  202.     of the name).  An encoding where the length of the code for the symbols
  203.     depends on the frequency of the symbols.  Frequent symbols have shorter
  204.     codes than infrequent symbols.  The normal method is to first scan the
  205.     file to be compressed, and to assign codes when this is done (see for
  206.     instance: D. E. Knuth, the Art of Computer Programming).  Later methods
  207.     have been designed to create the codes adaptively; for a survey see:
  208.     Jeremy S. Vetter, Design and Analysis of Dynamic Huffman Codes, JACM,
  209.     Vol 34, No 4, Oct 1987, pp 825-845.
  210. LZ77: The first of two Ziv-Lempel methods.  Using a window of past encoded
  211.     text, output consists of triples for each sequence of newly encoded
  212.     symbols: a back pointer and length of past text to be repeated and the
  213.     first symbol that is not part of that sequence.  Later versions allowed
  214.     deviation from the strict alternation of pointers and uncoded symbols
  215.     (LZSS by Bell).  Later Brent included Huffman coding of the pointers
  216.     (LZH).
  217. LZ78: While LZ77 uses a window of already encoded text as a dictionary,
  218.     LZ78 dynamically builds the dictionary.  Here again pointers are strictly
  219.     alternated with unencoded new symbols.  Later Welch (LZW) managed to
  220.     eliminate the output of unencoded symbols.  This algorithm is about
  221.     the same as the one independently invented by Miller and Wegman (MW).
  222.     A problem with these two schemes is that they are patented.  Thomas
  223.     modified LZW to LZC (as used in the Unix compress command).  While LZ78
  224.     and LZW become static once the dictionary is full, LZC has possibilities
  225.     to reset the dictionary.  Many LZC variants are in use, depending on the
  226.     size of memory available.  They are distinguished by the maximum number
  227.     of bits that are used in a code.
  228. A number of other schemes are proposed and occasionally used.  The main
  229. advantage of the LZ type schemes is that (especially) decoding is fairly fast.
  230.  
  231. Programs background:
  232.  
  233. Plain programs:
  234. BinHex 5.0:
  235.     Unlike what its name suggest this is not a true successor of BinHex 4.0.
  236.     BinHex 5.0 takes the MacBinary form of a file and stores it in the data
  237.     fork of the newly created file.
  238.     Although BinHex 5.0 does not create BinHex 4.0 compatible files, StuffIt
  239.     will give the creator type of BinHex 5.0 (BnHq) to its binhexed files,
  240.     rather than the creator type of BinHex 4.0 (BNHQ).  The program knows
  241.     about that.
  242. MacBinary:
  243.     As its name suggests, it does the same as BinHex 5.0.
  244. UMCP:
  245.     Looks similar, but the file as stored by UMCP is not true MacBinary.
  246.     Size fields are modified, the result is not padded to a multiple of 128,
  247.     etc.  Macunpack deals with all that, but until now is not able to
  248.     correctly restore the finder flags of the original file.  Also, UMCP
  249.     created files have type "TEXT" and creator "ttxt", which can create a
  250.     bit of confusion.  Macunpack will recognize these files only if the
  251.     creator has been modified to "UMcp".
  252.  
  253. Compressors:
  254. ShrinkToFit:
  255.     This program uses a Huffman code to compress.  It has an option (default
  256.     checked for some reason), COMP, for which I do not yet know the
  257.     meaning.  Compressing more than a single file in a single run results
  258.     in a failure for the second and subsequent files.
  259. Compress It:
  260.     Also uses a Huffman code to compress.
  261. MacCompress:
  262.     MacCompress has two modes of operation, the first mode is (confusingly)
  263.     MacCompress, the second mode is (again confusingly) UnixCompress.  In
  264.     MacCompress mode both forks are compressed using the LZC algorithm.
  265.     In UnixCompress mode only the data fork is compressed, and some shuffling
  266.     of resources is performed.  Upto now macunpack only deals with MacCompress
  267.     mode.  The LZC variant MacCompress uses depends on memory availability.
  268.     12 bit to 16 bit LZC can be used.
  269.  
  270. Archivers:
  271. ArcMac:
  272.     Nearly PC-Arc compatible.  Arc knows 8 compression methods, I have seen
  273.     all of them used by ArcMac, except the LZW techniques.  Here they are:
  274.     1:    No compression, shorter header
  275.     2:    No compression
  276.     3:    (packing) Run length encoding
  277.     4:    (squeezing) RLE followed by Huffman encoding
  278.     5:    (crunching) LZW
  279.     6:    (crunching) RLE followed by LZW
  280.     7:    (crunching) as the previous but with a different hash function
  281.     8:    (crunching) RLE followed by 12-bit LZC
  282.     9:    (squashing) 13-bit LZC
  283. PackIt:
  284.     When archiving a file PackIt either stores the file uncompressed or
  285.     stores the file Huffman encoded.  In the latter case both forks are
  286.     encoded using the same Huffman tree.
  287. StuffIt and StuffIt Classic/Deluxe:
  288.     These have the ability to use different methods for the two forks of a
  289.     file.  The following standard methods I do know about (the last three
  290.     are only used by the Classic/Deluxe version 2.0 of StuffIt):
  291.     0:    No compression
  292.     1:    Run length encoding
  293.     2:    14-bit LZC compression
  294.     3:    Huffman encoding
  295.     5:    LZAH: like LZH, but the Huffman coding used is adaptive
  296.     6:    A Huffman encoding using a fixed (built-in) Huffman tree
  297.     8:    A MW encoding
  298. Diamond:
  299.     Uses a LZ77 like frontend plus a Fraenkel-Klein like backend (see
  300.     Apostolico & Galil, Combinatorial Algorithms on Words, pages 169-183).
  301. Compactor/Compact Pro:
  302.     Like StuffIt, different encodings are possible for data and resource fork.
  303.     Only two possible methods are used:
  304.     0:    Run length encoding
  305.     1:    RLE followed by some form of LZH
  306. Zoom:
  307.     Data and resource fork are compressed with the same method.  The standard
  308.     uses either no compression or some form of LZH
  309. MacLHa:
  310.     Has two basic modes of operation, Mac mode and Normal mode.  In Mac mode
  311.     the file is archived in MacBinary form.  In normal mode only the forks
  312.     are archived.  Normal mode should not be used (and can not be unpacked
  313.     by macunpack) as all information about data fork size/resource fork size,
  314.     type, creator etc. is lost.  It knows quite a few methods, some are
  315.     probably only used in older versions, the only methods I have seen used
  316.     are -lh0-, -lh1- and -lh5-.  Methods known by MacLHa:
  317.     -lz4-:  No compression
  318.     -lz5-:  LZSS
  319.     -lzs-:  LZSS, another variant
  320.     -lh0-:  No compression
  321.     -lh1-:  LZAH (see StuffIt)
  322.     -lh2-:  Another form of LZAH
  323.     -lh3-:  A form of LZH, different from the next two
  324.     -lh4-:  LZH with a 4096 byte buffer (as far as I can see the coding in
  325.         MacLHa is wrong)
  326.     -lh5-:  LZH with a 8192 byte buffer
  327. DiskDoubler:
  328.     The older version of DiskDoubler is compatible with MacCompress.  It does
  329.     not create archives, it only compresses files.  The newer version (since
  330.     3.0) does both archiving and compression.  The older version uses LZC as
  331.     its compression algorithm, the newer version knows a number of different
  332.     compression algorithms.  Many (all?) are algorithms used in other
  333.     archivers.  Probably this is done to simplify conversion from other formats
  334.     to DiskDoubler format archives.  I have seen actual DiskDoubler archives
  335.     that used methods 0, 1 and 8:
  336.     0:    No compression
  337.     1:    LZC
  338.     2:    unknown
  339.     3:    RLE
  340.     4:    Huffman (or no compression)
  341.     5:    unknown
  342.     6:    unknown
  343.     7:    An improved form of LZSS
  344.     8:    Compactor/Compact Pro compatible RLE/LZH or RLE only
  345.     9:    unknown
  346.     The DiskDoubler archive format contains many subtle twists that make it
  347.     difficult to properly read the archive (or perhaps this is on purpose?).
  348.  
  349. Naming:
  350. Some people have complained about the name conflict with the unpack utility
  351. that is already available on Sys V boxes.  I had forgotten it, so there
  352. really was a problem.  The best way to solve it was to trash pack/unpack/pcat
  353. and replace it by compress/uncompress/zcat.  Sure, man uses it; but man uses
  354. pcat, so you can retain pcat.  If that was not an option you were able to feel
  355. free to rename the program.  But finally I relented.  It is now macunpack.
  356.  
  357. When you have problems unpacking an archive feel free to ask for information.
  358. I am especially keen when the program detects an unknown method.  If you
  359. encounter such an archive, please, mail a 'binhexed' copy of the archive
  360. to me so that I can deal with it.  Password protected archives are (as
  361. already stated) not implemented.  I do not have much inclination to do that.
  362. Also I feel no inclination to do multi-segment archives.
  363.  
  364. -------------------------------------------------------------------------------
  365. Hexbin will de-hexify files created in BinHex 4.0 compatible format (hqx)
  366. but also the older format (dl, hex and hcx).  Moreover it will uudecode
  367. files uuencoded by UUTool (the only program I know that does UU hexification
  368. of all Mac file information).
  369.  
  370. There are currently many programs that are able to create files in BinHex 4.0
  371. compatible format.  There are however some slight differences, and most
  372. de-hexifiers are not able to deal with all the variations.  This program is
  373. very simple minded.  First it will intuit (based on the input) whether the
  374. file is in dl, hex, hcx or hqx format.  Next it will de-hexify the file.
  375. When the format is hqx, it will check whether more files follow, and continue
  376. processing.  So you can catenate multiple (hqx) hexified files together and
  377. feed them as a single file to hexbin.  Also hexbin does not mind whether lines
  378. are separated by CR's, LF's or combinations of the two.  Moreover, it will
  379. strip all leading, trailing and intermediate garbage introduced by mailers
  380. etc.  Next, it does not mind if a file is not terminated by a CR or an LF
  381. (as StuffIt 1.5.1 and earlier did), but in that case a second file is not
  382. allowed to follow it.  Last, while most hexifiers output lines of equal length,
  383. some do not.  Hexbin will deal with that, but there are some caveats; see the
  384. -c option in the man page.
  385.  
  386. Background:
  387.  
  388. dl format:
  389.     This was the first hexified format used.  Programs to deal with it came
  390.     from SUMacC.  This format only coded resource forks, 4 bits in a byte.
  391. hex format:
  392.     I think this is the first format from Yves Lempereur.  Like dl format,
  393.     it codes 4 bits in a byte, but is able to code both resource and
  394.     data fork.  Is it BinHex 2.0?
  395. hcx format:
  396.     A compressing variant of hex format.  Codes 6 bits in a byte.
  397.     Is it BinHex 3.0?
  398. hqx format:
  399.     Like hcx, but using a different coding (possibly to allow for ASCII->EBCDIC
  400.     and EBCDIC->ASCII translation, which not always results in an identical
  401.     file).  Moreover this format also encodes the original Mac filename.
  402. mu format:
  403.     The conversion can be done by the UUTool program from Octavian Micro
  404.     Development.  It encodes both forks and also some finder info.  You will
  405.     in general not use this with uudecode on non Mac systems, with uudecode
  406.     only the data fork will be uudecoded.  UU hexification is well known (and
  407.     fairly old) in Unix environments.  Moreover it has been ported to lots of
  408.     other systems.
  409. -------------------------------------------------------------------------------
  410. Macsave reads a MacBinary stream from standard input and writes the
  411. files according to the options.
  412. -------------------------------------------------------------------------------
  413. Macstream reads files from the Unix host and will output a MacBinary stream
  414. containing all those files together with information about the directory
  415. structure.
  416. -------------------------------------------------------------------------------
  417. Binhex will read a MacBinary stream, or will read files/directories as
  418. indicated on the command line, and will output all files in binhexed (.hqx)
  419. format.  Information about the directory structure is lost.
  420. -------------------------------------------------------------------------------
  421. Tomac will transmit a MacBinary stream, or named files to the Mac using
  422. the XMODEM protocol.
  423. -------------------------------------------------------------------------------
  424. Frommac will receive one or more files from the Mac using the XMODEM protocol.
  425. -------------------------------------------------------------------------------
  426. This is an ongoing project, more stuff will appear.
  427.  
  428. All comments are still welcome.  Thanks for the comments I already received.
  429.  
  430. dik t. winter, amsterdam, nederland
  431. email: dik@cwi.nl
  432.  
  433. --
  434. Note:
  435. In these programs all algorithms are implemented based on publicly available
  436. software to prevent any claim that would prevent redistribution due to
  437. Copyright.  Although parts of the code would indeed fall under the Copyright
  438. by the original author, use and redistribution of all such code is explicitly
  439. allowed.  For some parts of it the GNU software license does apply.
  440. --
  441. Appendix.
  442.  
  443. BinHex 4.0 compatible file creators:
  444.  
  445. Type    Creator        Created by
  446.  
  447. "TEXT"    "BthX"        BinHqx
  448. "TEXT"    "BNHQ"        BinHex
  449. "TEXT"    "BnHq"        StuffIt and StuffIt Classic
  450. "TEXT"    "ttxt"        Compactor
  451.  
  452. Files recognized by macunpack:
  453.  
  454. Type    Creator        Recognized as
  455.  
  456. "APPL"    "DSEA"        "DiskDoubler"        Self extracting
  457. "APPL"    "EXTR"        "Compactor"        Self extracting
  458. "APPL"    "Mooz"        "Zoom"            Self extracting
  459. "APPL"    "Pack"        "Diamond"        Self extracting
  460. "APPL"    "arc@"        "ArcMac"        Self extracting (not yet)
  461. "APPL"    "aust"        "StuffIt"        Self extracting
  462. "ArCv"    "TrAS"        "AutoSqueeze"                (not yet)
  463. "COMP"    "STF "        "ShrinkToFit"
  464. "DD01"    "DDAP"        "DiskDoubler"
  465. "DDAR"    "DDAP"        "DiskDoubler"
  466. "DDF."    "DDAP"        "DiskDoubler" (any fourth character)
  467. "DDf."    "DDAP"        "DiskDoubler" (any fourth character)
  468. "LARC"    "LARC"        "MacLHa (LHARC)"
  469. "LHA "    "LARC"        "MacLHa (LHA)"
  470. "PACT"    "CPCT"        "Compactor"
  471. "PIT "    "PIT "        "PackIt"
  472. "Pack"    "Pack"        "Diamond"
  473. "SIT!"    "SIT!"        "StuffIt"
  474. "SITD"    "SIT!"        "StuffIt Deluxe"
  475. "Smal"    "Jdw "        "Compress It"
  476. "TEXT"    "BnHq"        "BinHex 5.0"
  477. "TEXT"    "GJBU"        "MacBinary 1.0"
  478. "TEXT"    "UMcp"        "UMCP"
  479. "ZIVM"    "LZIV"        "MacCompress(M)"
  480. "ZIVU"    "LZIV"        "MacCompress(U)"            (not yet)
  481. "mArc"    "arc*"        "ArcMac"                (not yet)
  482. "zooM"    "zooM"        "Zoom"
  483.  
  484.